老闆跟產品經理怎麼知道設計什麼產品會成功?坦白說，除了能預知未來，不然沒有人知道。產品經理當然有很多方法可以盡可能的在正式進入開發前透過有效的驗證方式增加產品的成功機率(請參考這篇[需求驗證] 怎麼知道客戶要什麼?)，但是想要真知道產品是否真的成功，只要真正實際上試了才知道。而這也就是為什麼很多公司是透過不斷地實驗與改進取得成功。在亞馬遜，實驗的文化相當流行，以下節錄兩段貝佐斯說過的話，就可以知道實驗在亞馬遜內扮演多重要的角色。

在亞馬遜，我們的成功是建立在每年，每月，每周，每日做了多少實驗上 (Our success at Amazon is a function of how many experiments we do per year, per month, per week, per day)
-Jeff Bezos

為了要創新你需要進行實驗。如果你已經知道什麼事情會成功，那可稱不上實驗 (To invent you have to experiment, and if you know in advance that it’s going to work, it’s not an experiment.)
-Jeff Bezos

因此今天的文章想跟大家分享一種做實驗的方法，叫做假設驅動開發(Hypothesis Driven Development, HDD)。

什麼是假設驅動開發 Hypothesis Driven Development

Hypothesis Driven Development(簡稱HDD)代表產品的開發是被假設(Hypothesis)所驅動的。因此，我們在產品開發前會先有一個產品假設，然後透過開發來進行實驗，並且檢視實驗結果來驗證這個假設是否成立，然後根據實驗結果進行調整與優化，最終決定產品功能。透過HDD，我們在開發時可以很清楚我們希望解決的問題與達成的目標，並且可以透過結果驗證是否我們正朝著對的方向前進。

Ref: https://imarunrk.medium.com/hypothesis-driven-development-ecfb5f5a889e

如何進行假設驅動開發?

首先，假設通常是以這樣的形式存在:

因為某些目標客戶(Target Customer)存在什麼痛點(Problem)，我們認為提供這個解決方案(Feature)給目標客戶，可以解決他們的問題並使他們感到滿意，進而達成什麼企業目標(Success critera)。

因此，假設驅動開發可以分成以下幾個步驟:

第一步，寫出問題陳述 (Problem Statement)

關於好的問題陳述可以參考我的這篇文章:[問題陳述] 把用戶問題說清楚很難?試試這招，這裡就不重新展開。

第二步，證明問題真實存在

很多人在這個時候就會直接跳到下一步，而忽略了這個超級重要的步驟。在我們開始嘗試解決這個問題之前，我們能否證明這個問題是真實存在的? 假設驅動開發應該著重在透過實驗嘗試各種功能是否能夠解決客戶遇到的問題，所以確認問題是正確的非常重要! 我們可以透過使用者行為紀錄(user behavior log)進行量化分析找出問題，或是透過使用者訪談與問卷方式進行調查，確認這個問題是否真實存在且對使用者來說具備一定的嚴重性與急迫性。這樣才不會花了很多的時間與資源在解決錯的問題上面。

第三步，假設驗證支持

在之前的需求驗證階段是否已經有一些資料或數據可以用以支持這個假設，在還沒有正式進入開發前，如果已經初步做了驗證，可以幫助我們在下一步撰寫假設陳述時更有證據加以支持，也更能讓老闆與工程師支持與了解我們進行這次的實驗。

第四步，寫出假設陳述 (Hypothesis Statement)

在寫出假設陳述時，通常包含了以下幾個元素: 客戶問題、產品功能與衡量指標。我們可以參考以下的範例進行撰寫:

如果我們的產品提供了 (產品功能) 給 (某群目標客戶)，我們有信心可以解決 (客戶問題)， 讓 (衡量指標) 符合 (最低成功門檻)

在這個假設陳述中，我們清楚描述了包括使用者，問題與功能，同時也設定了衡量指標與最低成功門檻。如果最終的實驗結果衡量指標有超越最低成功門檻，我們就可以說這個假設是成立的，並且讓產品功能正式上線。因此在這個階段，需要制定出衡量指標與其目標。

關於指標的部分，可以分為商業指標(Business Level Metrics)、產品功能指標(Feature Level Metrics)與相關觀察指標(Help Metrics)分別觀察。透過這三種指標就可以幫助我們在實驗結果出來之後做出更好的判斷。

• 商業指標(Business Level Metrics): 直接影響到企業的指標，例如收入、購買率、客戶留存率、ROI等等
• 產品功能指標(Feature Level Metrics): 與功能直接有關的指標，例如使用率，使用滿意度等等
• 相關觀察指標(Help Metrics): 因為這個功能上線後可能會影響到的相關指標。例如觀察現有功能的使用率確認這個功能是否會影響到既有功能。或是這個功能背後有AI模型支持，觀察AI模型的表現像是Precision rate&Recall rate等等。

第五步，實驗計畫與進行實驗 (Experiment Plan)

在這個階段，則需要描述整個實驗的計畫如何進行，包括實驗的方式(像是A/B test就需要描述怎麼切分A/B group)，時程預計多久，預計有多少的資料量等等。在確認實驗計畫與整個時程後，就可以請工程師開始進行開發。

第六步，實驗結果分析 (Result Review and Analysis)

實驗結果出來之後，針對結果進行分析，別忘了實驗也是一個迭代的過程，並不是一次結果出來之後只有Go/No go兩種，如果實驗結果出來指標都超過最低成功標準，那就可以Go。但如果沒有，則需要進行更多的分析來確定我們要採取哪種下一步行動:

• 優化(Optimize): 當功能確實有傳遞出對使用者的好處但仍有空間可以改進時
• 重新設計(Re-design): 當發現可能跟預期的有所差距時
• 回復之前版本(Roll Back): 當發現這個功能對某些指標造成負面影響時，例如反而造成公司收入降低或是負評大幅增加時，則可能需要直接回復到之前的版本。

結語

做實驗現在是身為一個產品經理的必備技能，有越來越多的公司擁抱實驗，藉以實現產品上的成功。而假設驅動開發(HDD)提供了一個很好的做實驗框架，可以讓大家透過實驗持續地學習並改進我們的產品，並且驅動產品與企業業務上的成功。今天分享了當工程師看到一個實驗的功能在Scrum中出現時，PM們背後默默做的實驗準備，希望能對大家有所幫助!

Ref: 網路